Publish/subscribe communications involve information producers publishing information or events to a publish/subscribe system, and information consumers subscribing to particular categories of information or events and receiving relevant publications from the system. The publish/subscribe system may comprise a message broker, located between publisher and subscriber applications, which delivers published information or events to all interested subscribers.
The publish/subscribe communication paradigm supports many-to-many communications in which individual publishers and subscribers may be anonymous to each other (communicating via an intermediate broker) and can be easily added and removed from the network without disruption. An example message broker is the IBM® WebSphere® Business Integration Message Broker product available from IBM. (IBM and WebSphere are registered trademarks of International Business Machines Corporation.)
Many publish/subscribe messaging systems are subject-based. In these systems, each message belongs to one of a predefined set of subjects (also known as channels, or topics). Publishers label each message with a subject, and consumers subscribe to all the messages having a particular subject label. For example, a subject-based publish/subscribe system for stock trading may use a defined topic name for each stock issue—publishers post information using the appropriate topic name and subscribers include topic names when specifying which stocks they wish to receive information about.
Some messaging systems provide a replay feature, for example retaining publications for replay to new subscribers (and newly recovered subscribers) so that the new subscribers are able to receive some or all of an earlier message feed.
In a replay system the messages for replay are stored in a data store. There is a danger, that after a certain period of time, the data store can become over populated with stored messages and thus become difficult to manage. Thus a pruning strategy is deployed by the replay system to provide data management of the data store.
A pruning strategy works by scanning the data store for messages that have been stored for a particular length of time, for example. The length of time is variable and can be altered by an administrator. If the pruning component locates messages that meet the pruning strategy's criterion, a pruning operation is performed and the identified messages are removed from the data store. A problem often occurs when a message is requested for replay, but the request has to be declined because the message has been pruned from the data store. Hence there is a need within the art to provide a solution to this problem.